Many present day computing systems implement “virtualization”. A typical implementation is illustrated in FIG. 1. As observed in FIG. 1, a layer of software 102 is imposed between the operating system 101 software and the CPU 103. This layer of software 102 typically includes one or more virtual machines (VMs) 102a_1-102a_N that “run on top” of a virtual machine monitor (VMM) 102b. Although not a strict requirement, FIG. 1 shows a common arrangement where different software application instances 100_1-100_N are each provided with its own operating system instance 101_1-101_N that runs on top of a dedicated virtual machine 102a_1-102a_N.
A VM presents the appearance of a CPU to the software that runs on it; such software is often known as “guest” software. As a consequence, at least as a first approximation, the software running on the virtual machine may “think” that it has the resources of an entire computer system to itself. The VMM 102b is responsible for supporting multiple VMs on an underlying CPU 103. As such, the VMM 102b coordinates the concurrent requests/needs of the multiple VMs on the CPU 103. This includes correlating allocations of actual resources of the underlying computing system (e.g., CPU threads, system memory space, disk drive storage space, etc.) to the “virtual” computing system resources that the software running on the VMs refer to.
While guest software normally “thinks” that it running on its own computer system with no VMM, it is also possible for such software to be designed to know when it is running in a VM supported by a VMM. Such software is sometimes called “paravirtualized” or “enlightened.” Software that “knows” it is running on a VMM (e.g., in one of the VMs 102a_1-102a_N) may be designed to directly invoke certain “services” provided by the VMM 102b. Presently, however, in order to invoke a VMM service, control of the CPU must first pass to the VMM from the VM in which the application/OS instance making the invocation is running; this control transfer is sometimes referred to as a “VM exit”. One possible consequence of a VM exit is that the CPU must “switch” its active context or state from that of the VM's process to that of a VMM process. After the service has been completed, the CPU must again switch its active context/state back from the VMM process to the VM process; this return control transfer is sometimes referred to as a “VM entry.”
FIG. 2 shows a prior art process for invoking a VMM service. As observed in FIG. 2, an application/OS instance recognizes a need to invoke a VMM service 201. Prior to the invocation, the application/OS instance may populate 202 registers and/or memory with values that identify the specific service being invoked and the service's input parameters. To then invoke the VMM service, the application/OS instance executes an instruction 203 for invoking the VMM service. For example, in the case of present day Intel processors having VT-x technology, the application/OS instance executes the VMCALL instruction, which was designed for calling the VMM explicitly from a process that is being run on a VM. (The application/OS instance might instead use another instruction, such as CPUID or WRMSR, that causes VM exits and that the VMM has enabled for this purpose.)
In response to the VMCALL instruction being executed, control of the CPU is transferred from the VM to the VMM 203 (VM exit). In operation, microcode within the CPU implements the aforementioned context/state switching by moving the context/state information of the VM from software visible CPU register space to the Virtual-Machine Control Structure (VMCS), which has been configured by the VMM, and reloading much of these same software visible registers with context/state information for the VMM process from elsewhere in the VMCS.
The VMM process refers to the memory or register values established by the invoking application/OS instance to understand what service is being requested and to accesses the service's input parameters. The VMM process then executes the service 204. This is accomplished by executing VMM program code written to perform the service.
After the service is completed, control transfers back from the VMM to the VM by way of a VM entry 205. Here, CPU microcode loads the VM context/state from the VMCS into the software visible register space.
An example of a VMM service is a “guest address space switching” service. This service may be useful to guest software running in virtual machines for which a VMM supports multiple address spaces, as explained in the following paragraphs.
A VMM typically supports, for each of its VMs, a “guest address space”. This is a mapping from the addresses that the guest “thinks” are physical (guest-physical addresses) to true physical addresses that can be used to access memory; the mapping may also specify access rights (e.g., read/write, read-only, etc.) for each guest-physical address. In the case of present day Intel processors having VT-x technology, guest address spaces may be implemented using extended page tables (EPT).
In the absence of paravirtualization, a VMM will typically support a single guest address space per VM. If guest software is paravirtualized, a VMM may establish multiple guest address spaces for a single VM, although only one will be active at a time. In one example, these address spaces may differ from each other with regard to how different regions of memory are protected. There might be a different guest address space for each application module running in the VM; the guest address space for a module might allow the module to access its own memory but not the memory belonging to other modules.
For a VM supported by multiple guest address spaces, the VMM will need to change which guest address space is active when appropriate. An efficient mechanism is for guest software to inform the VMM when to change the guest address space (e.g., when the guest OS is changing from one application module to another). Guest software can inform the VMM via a “guest address space switching” service.
As noted earlier, the VMCALL or other instruction can be executed to call the VMM for the guest address space switching service. Prior to execution of the instruction, the guest software may place a value in a register (e.g., an EAX register) or memory to identify the “guest address space switching” service. An identifier of the address space to be switched to may be specified in an additional register (e.g., the EBX register) or in memory. The instruction causes a VM exit, and the service is performed as described above by the VMM.